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The payee travels to any authorized ATM location and accesses the ATM providing the PIN code 
and any other required validation information. The ATM terminal authenticates the provided 
information with the payment information stored at the ATM control server. Where the 
information is validated, the payment request is transmitted to the ATM terminal, which instructs 
5 the terminal to dispense the indicated amount. In this manner, the payee is free to use any 
convenient authorized ATM terminal to collect the cash payment. 

Fig. 3 presents a block diagram that builds on the system presented in Fig. 2 by 
adding support for multiple ATM systems, 201 and 300. At the time the payor makes a payment 
request, he or she is optionally permitted to indicate the particular ATM terminal, 1 12 and 308, 

ig used to dispense the payment. This terminal data is included in the payment request along with, 
as indicated above, a data code indicating the terminal type, e.g., ATM system that is the ultimate 
destination for the payment request. 

The payment request is transmitted to the cash payment server 1 1 8, where it is 

G passed to the request translation software 209 via its P2P interface 210 for translation. Because 

lg this is a heterogeneous computing environment comprising multiple ATM control server types, 
1 14 and 304, each processing payment requests according to a disparate format, the proper ATM 
control interface, 212 and 302, is selected according to the terminal type data code contained in 
the payment request. The request translation software 209 processes the terminal type data block 
of the payment request and determines which interface is a match. This processing may be 

20 executed in a parallel or serial manner. Where a match is found, the interface translates the 

message into the native format of the ATM system it is programmed for. Once the appropriate 
interface is determined, processing is completed as previously described. 
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Fig. 4 presents a high-level flow diagram presenting a method of operating 
embodiments of the system presented in Figs, la through 3. A buyer or payor accesses a P2P 
system through the use of P2P client software and generates an account with the system, step 
402. The account registration procedure includes, but is not limited to, collecting personal 
information regarding the payor and the funds source used to make payments for purchases. The 
funds source may be, for example, a smart card, a stored value card, a checking or savings 
account, credit card, or debit card. 

Using the P2P system, the payor selects goods and services for purchase and sets 
up a payment, step 404. The P2P system uses the funds source information provided by the 
payor at the time of registration, step 402, to debit the amount of the transaction from the funds 
source, step 406. The payment request is then translated from the native format of the P2P 
system into the native format of the ATM system, step 407. The ATM system generates a PIN 
code and notification message for eventual transmission to the payee, step 408. The ATM 
system also transmits a payment instruction and PIN code to an ATM, step 410, enabling the 
ATM to dispense the amount of currency contained in the payment instruction when the 
associated PIN is entered into the ATM. 

The notification and PIN code generated in step 408 are translated from the native 
format of the ATM system into the native format of the P2P system, step 412. The P2P system 
delivers the notification and PIN code to the payee device, step 414, instructing the payee as to 
the location of the ATM instructed to dispense the currency for payment. The payee travels to 
the location of the ATM and supplies the received PIN code, step 416, which causes the ATM to 
dispense the funds. 
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Fig. 5 is a detailed flow diagram of the method of operation presented in Fig. 4. 
Using a computing device as previously described, the payor submits a request for payment via 
the P2P system, step 502. The request is received by the P2P server and processed by the P2P 
server software, step 504. P2P server software performs a check to determine if the payor has an 
5 account with the system by searching account records, step 506. Where the check fails to 
uncover a payor account, step 506, the P2P server software executes a new account subroutine 
that involves the payor answering a series of questions regarding personal information and fund 
source information, the fund source information used to fund transactions executed through the 
P2P system, step 508. 

1J When the new account subroutine ends, another check is performed to determine 

fy if the subroutine exited properly and all account information was collected, step 510. If the 
VI check fails, a third check is performed to determine if a predetermined threshold has been passed, 

step 511. Where the threshold has not been exceeded, step 511, another iteration of the loop is 
P executed, steps 508, 5 10, and 5 1 1 . If the threshold has been exceeded, step 5 1 1, the process ends 
l|j and the payment request is abandoned, step 513. 

Where the P2P server software determines that the payor has an account with the 
system, step 506, a check is performed to determine if the payor has sufficient funds available in 
the designated funds source to fulfill the payment request, step 512. If sufficient funds are 
unavailable, step 512, a check is performed to determine if a predetermined threshold has been 
20 passed, step 514. Where the threshold has not been exceeded, the software generates a request 
for the payor to provide additional funds or additional fund sources in order to fund the payment 
request, step 516. The loop is reiterated until either the threshold is exceeded, step 514, causing 
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